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DETAILED ACTION 
Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Bradshaw et ah in view of Cheng et ah 

2. Claims 1, 4-5, 8-9, 12-13, 16-17, 20-21, 24, and 33-35 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Bradshaw et al. (USP 6,674,731) in view of 
Cheng et al. (USP 6,040,851). 

3. With regard to claims 1, 9, and 17, Bradshaw et al. discloses the transmission of 
TCP/IP data over a satellite link from a hub station to a plurality of remote terminal units 
[Abstract]. Bradshaw et al. further teaches user terminals [col. 4, lines 58-61] (hosts) 
connected to remote units [col. 4, lines 65-67] (terminal unit). The remote unit contains a 
receiver [col. 4, lines 14-15] and a transmitter [Fig. 8] for two-way communication. 
Bradshaw et al. also teaches the hub use of DVB format data frames [col. 3, lines 47-49]. 
The receiver must contain a MAC to DVB converter [col. 12, lines 38-40] to conform to 
DVB protocol format that is supported by the hub [col. 3, line 49]. Bradshaw et al. also 
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teaches an RF receiver coupled to an antenna to permit exchange of data between the 
remote terminal and the satellite [Fig. 10]. A burst demodulator must be present in the 
RF receiver for demodulating the signal over the satellite link due to the nature of 
satellite communications. The data frame conforms with the DVB protocol format (i.e., 
the return channel frame format) [col. 3, line 49]. The hub station [Fig. 2, 104] is shown 
with the antenna and the RF transmitter/receiver. Thus, these elements are interpreted as 
containing the satellite-to-hub interface. Bradshaw et al. further discloses that the hub is 
connected to an external packet switched network [Fig. 2, element 24; col. 4, lines 25- 
29], which, in this case, is the internet. The hub must necessarily be able to convert the 
protocol data frames received from the satellite into requests to/from content servers [col. 
5, lines 13-17]. Bradshaw et al. also teaches a multi-layer protocol interface for the hub- 
to-terminal interface as the TCP/IP data is encapsulated into a MAC data frame [col. 7, 
lines 62-63] and because the TCP/IP frames are also formatted within the DVB frame 
[col. 8, lines 47-51]. 

Bradshaw et al. fails to specifically disclose the transmission of data bursts from 
the terminal to the host via a direct USB connection. Bradshaw et al. discloses that the 
connection between the remote unit 108 A (terminal) and the user terminal 1 18A (host) is 
a LAN 1 16 [Fig. 2]. Bradshaw et al. can use a standardized bus (e.g., the IEEE 802.6 
DQDB) for conveying bursty video, which also has the advantage of improved 
performance characteristics [see generally, col. 3, lines 65-67]. Thus, the remote unit 
108 A (terminal) in Bradshaw et al. receives the wireless signals from satellite 106 and 
transports them to the user terminal 1 18A host via a LAN 116 [Fig. 2]. A LAN involves 
much more complexity in connecting devices, such as the remote unit 108 A (terminal), to 
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multiple user terminals 1 18A (hosts) [See Id.]. Furthermore, a remote unit 108 A 
(terminal) requires an interface and a driver in order to condition the signal and provide 
the physical interface to the LAN [col. 14, lines 15-23]. LAN 1 16 allows remote unit 
108 A (terminal) to transport information in multiple formats/standards to those multiple 
user terminals 1 18A (hosts), which are connected to LAN 116. It is well known to those 
skilled in the art to use a direct connection between a terminal and host, instead of a 
LAN, because such a connection reduces the complexity of communicating over a LAN 
and allows more direct and efficient communications between the two devices. 

Cheng et al. (USP 6,040,851) discloses a set-top box along with a receiver sub- 
system that integrates network-dependent functions into a digital interface conditional 
access module (DICAM) (host interface) which then can implement bursty video 
[MPEG 1, 2, or 3, col. 6, line 25] from a variety of sources (to include satellite dishes 
and cable) and then implement them on a personal computer (host) to receive the data 
[Abstract; col. 1, lines 11-33]. Cheng et al. uses the combination of a set-top universal 
box (STUB) (terminal) and the DICAM (host interface) to separate out the network- 
dependent and network-independent streams and functions [Figs. 3-5; col. 2, lines 8-17]. 
Thus, Cheng et al.'s STUB/DICAM [Figs. 3-5] receives satellite input signals [col. 6, 
line 16] and outputs the data/streams via a direct connection such as a universal serial bus 
(USB) [col. 6, lines 20-26]. A USB bus specifically supports (common) bursty video 
traffic. Bradshaw et al. and Cheng et al. both involve the transmission and reception of 
data over a wireless communication channel [both receive satellite signals]. Moreover, 
both Bradshaw et al. and Cheng et al. disclose integrated services, specifically, 
transmitting the received data to a user terminal [user terminal 1 18A in Bradshaw et al. 
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and a PC in Cheng et al.]. Thus, it would have been obvious to one of ordinary skill in 
the art at the time of the invention to have used the received satellite communications of 
Bradshaw et al. with the less-complex and directly-connected USB bus disclosed in 
Cheng et al. to connect the remote unit 108 A (terminal) and the user terminal 1 18A (host) 
because integrated services require interoperability between the receipt, and use, of 
bursty video data transmissions which contribute to improved performance 
characteristics. 

4. With regard to claims 4, 12, and 20, Bradshaw et al. discloses all teaches that MPEG 
format data is packaged into DVB protocol format [col. 2, lines 66-67], and TCP/IP data 
is encapsulated into an Ethernet MAC data frame [col. 7, lines 62-63], that is, multi-layer 
protocol with support for DVB. 

5. With regard to claim 5, Bradshaw et al. discloses that the data exchanged over the 
satellite link is TCP/IP [col. 3, lines 37-39] . 

6. With regard to claims 8, 16, and 24, Bradshaw et al. discloses that the packet-switched 
network is the internet [Fig. 2, element 24]. 

7. With regard to claims 13 and 21, Bradshaw et al. discloses IP [col. 7, lines 62-63], an 
IETF-standardized protocol used for interfacing receiver and transmitter units, as well as 
for transmitting data. 
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8. With regard to claims 33-35, neither Bradshaw et al. nor Cheng et al. specifically 
disclose using USB super frames to send data bursts to the host. Cheng et al. discloses a 
USB serial interface, which can handle bursty video and uses USB frames. It is well 
known to those skilled in the art that USB super frames can be used by devices sending 
video data (and other isochronous applications) when (a) there are large amounts of data 
to be sent; and (b) the device can reserve enough time slots to send the super frame 
[wherein problems with USB bus cycles and bandwidth can arise when the device has to 
contend with other devices on the same USB bus]. Since the combination of Bradshaw et 
al. and Cheng et al. teaches the less-complex and directly-connected USB bus between 
remote unit 108 A (terminal) and user terminal 1 18A (host), as noted above, it would have 
been obvious to one of ordinary skill in the art at the time of the invention to have used 
USB super frames to send large bursts of video data between remote unit 108 A (terminal) 
and user terminal 1 18A (host) because there would be no other device to contend with for 
the USB bus's cycle or bandwidth. 

Bradshaw et al in view of Cheng et al further in view of Birdwell et al 

9. Claims 6, 14, and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Bradshaw et al. in view of Cheng et al. as applied to claims 1, 9, and 17 above, and 
further in view of Birdwell et al. (US Patent Publication 2001/0024435). 

10. With regard to claims 6, 14, and 22, Bradshaw et al. does not specifically disclose 
little and big endian data formats. However, Birdwell et al. discloses endian formats for 
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IP packets transmitted over a satellite link [paragraph 0058]. Bradshaw et al. requires 
the determination of the beginning, the end, the LSB, and/or the MSB of the transmitted 
data frames in order to process the data frames. Endian formats aid in determining 
whether the first byte in the transmitted frames is the LSB or MSB. Thus, it would have 
been obvious to one of ordinary skill in the art at the time of the invention to have used 
the teachings of Bradshaw et al. in processing of transmitted data frames to have used the 
endian formats to aid in determining the LSB and MSB so that data alignment can be 
achieved at the receiver for either synchronization or CRC calculations. 

Bradshaw et al in view of Cheng et al further in view of Jorgenson et al 

11. Claims 7, 15, and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Bradshaw et al. in view of Cheng et al. as applied to claims 1, 9, and 17 above, and 
further in view of Jorgenson et al. (USP 6,680,922). 

12. With regard to claims 7, 15, and 23, Bradshaw et al. does not specifically disclose 
IGD packets. However, Jorgenson discloses UDP for transmission of packets over a 
wireless link [col. 12, lines 46-48]. IGD packets are formed from UDP packets. 
Therefore, it is obvious to those of ordinary skill in the art that UDP datagrams convey 
useful information parameters about the wireless link including the return channel ID and 
loading information. Moreover, UDP/IP packets encapsulate multiple data types, 
including IGD packets. 
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Brads haw et ah in view of Cheng et al. further in view of Dillon et al 

13. Claims 25, 28, 29, and 32 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Bradshaw et al. in view of Cheng et al. and further in view of Dillon et al. (USP 
6,338,131). 

14. With regard to claim 25, Bradshaw et al. discloses the transmission of TCP/IP data 
over a satellite link from a hub station to a plurality of remote terminal units [Abstract]. 
Bradshaw et al. further teaches user terminals [col. 4, lines 58-61] (hosts) connected to 
remote units [col. 4, lines 65-67] (terminal unit). The remote unit contains a receiver [col. 
4, lines 14-15] and a transmitter [Fig. 8] for two-way communication. Bradshaw et al. 
also teaches the hub use of DVB format data frames [col. 3, lines 47-49]. The receiver 
must contains a MAC to DVB converter [col. 12, lines 38-40] to conform to DVB 
protocol format that is supported by the hub [col. 3, line 49], Bradshaw et al. also 
teaches an RF receiver coupled to an antenna to permit exchange of data between the 
remote terminal and the satellite [Fig. 10]. A burst demodulator must be present in the 
RF receiver for demodulating the signal over the satellite link due to the nature of 
satellite communications. The data frame conforms with the DVB protocol format (i.e., 
the return channel frame format) [col. 3, line 49]. The hub station [Fig. 2, 104] is shown 
with the antenna and the RF transmitter/receiver. Thus, these elements are interpreted as 
containing the satellite-to-hub interface. Bradshaw et al. further discloses that the hub is 
connected to an external packet switched network [Fig. 2, element 24; col. 4, lines 25- 
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29], which, in this case, is the internet. The hub must necessarily be able to convert the 
protocol data frames received from the satellite into requests to/from content servers [col. 
5, lines 13-17]. Bradshaw et al. also teaches a multi-layer protocol interface for the hub- 
to-terminal interface as the TCP/IP data is encapsulated into a MAC data frame [col. 7, 
lines 62-63] and because the TCP/IP frames are also formatted within the DVB frame 
[col. 8, lines 47-51] 

Bradshaw et al. fails to specifically disclose the transmission of data bursts from 
the terminal to the host via a direct USB connection. Bradshaw et al. discloses that the 
connection between the remote unit 108 A (terminal) and the user terminal 1 18A (host) is 
a LAN 116 [Fig. 2]. Bradshaw et al. can use a standardized bus (e.g., the IEEE 802.6 
DQDB) for conveying bursty video, which also has the advantage of improved 
performance characteristics [see generally, col. 3, lines 65-67]. Thus, the remote unit 
108 A (terminal) in Bradshaw et al. receives the wireless signals from satellite 106 and 
transports them to the user terminal 1 18A host via a LAN 116 [Fig. 2]. A LAN involves 
much more complexity in connecting devices, such as the remote unit 108 A (terminal), to 
multiple user terminals 1 18A (hosts) [See Id.]. Furthermore, a remote unit 108 A 
(terminal) requires an interface and a driver in order to condition the signal and provide 
the physical interface to the LAN [col. 14, lines 15-23]. LAN 1 16 allows remote unit 
108 A (terminal) to transport information in multiple formats/standards to those multiple 
user terminals 1 18A (hosts), which are connected to LAN 116. It is well known to those 
skilled in the art to use a direct connection between a terminal and host, instead of a 
LAN, because such a connection reduces the complexity of communicating over a LAN 
and allows more direct and efficient communications between the two devices. 
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Cheng et al. (USP 6,040,851) discloses a set-top box along with a receiver sub- 
system that integrates network-dependent functions into a digital interface conditional 
access module (DICAM) (host interface) which then can implement bursty video 
[MPEG 1, 2, or 3, col. 6, line 25] from a variety of sources (to include satellite dishes 
and cable) and then implement them on a personal computer (host) to receive the data 
[Abstract; col. 1, lines 11-33]. Cheng et al. uses the combination of a set-top universal 
box (STUB) (terminal) and the DICAM (host interface) to separate out the network- 
dependent and network-independent streams and functions [Figs. 3-5; col. 2, lines 8-17], 
Thus, Cheng et al.'s STUB/DICAM [Figs. 3-5] receives satellite input signals [col. 6, 
line 16] and outputs the data/streams via a direct connection such as a universal serial bus 
(USB) [col. 6, lines 20-26]. A USB bus specifically supports (common) bursty video 
traffic. Bradshaw et al. and Cheng et al. both involve the transmission and reception of 
data over a wireless communication channel [both receive satellite signals]. Moreover, 
both Bradshaw et al. and Cheng et al. disclose integrated services, specifically, 
transmitting the received data to a user terminal [user terminal 1 18A in Bradshaw et al. 
and a PC in Cheng et al.]. Thus, it would have been obvious to one of ordinary skill in 
the art at the time of the invention to have used the received satellite communications of 
Bradshaw et al. with the less-complex and directly-connected USB bus disclosed in 
Cheng et al. to connect the remote unit 108 A (terminal) and the user terminal 1 18A (host) 
because integrated services require interoperability between the receipt, and use, of 
bursty video data transmissions which contribute to improved performance 
characteristics. 
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15. With regard to claim 28, Bradshaw et al. does not specifically disclose processors 
executing instructions to configure one or more of the interfaces. However, Dillon et al. 
discloses a satellite-based internet access system. The system of Dillon et al. contains 
several elements, including an application server and interface, hybrid gateway, and 
satellite gateway. A processor, executing instructions stored in memory may configure 
the gateway and the interfaces [col. 3, lines 59-62]. It is obvious to one of ordinary skill 
in the art that the same processor operating under instructions stored in memory, can also 
configure other/multiple interfaces. Thus, it would have been obvious to one of ordinary 
skill in the art at the time of the invention to combine the two-way satellite 
communications system of Bradshaw et al. to include the stored instructions executing in 
the processors of Dillon et al. because integrated services require interoperability between 
transmissions which contribute to improved performance characteristics as well as 
universal compatibility as well as flexibility. 

16. With regard to claim 29, Bradshaw et al. discloses IP [col. 7, lines 62-63], an IETF- 
standardized protocol used for interfacing receiver and transmitter units, as well as for 
transmitting data. 

17. With regard to claim 32, Bradshaw et al. discloses that the packet-switched network 
is the internet [Fig. 2, element 24]. 

18. With regard to claim 36, neither Bradshaw et al. nor Cheng et al. specifically disclose 
using USB super frames to send data bursts to the host. Cheng et al. discloses a USB 
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serial interface, which can handle bursty video and uses USB frames. It is well known to 
those skilled in the art that USB super frames can be used by devices sending video data 
(and other isochronous applications) when (a) there are large amounts of data to be sent; 
and (b) the device can reserve enough time slots to send the super frame [wherein 
problems with USB bus cycles and bandwidth can arise when the device has to contend 
with other devices on the same USB bus]. Since the combination of Bradshaw et al. and 
Cheng et al. teaches the less-complex and directly-connected USB bus between remote 
unit 108 A (terminal) and user terminal 1 18A (host), as noted above, it would have been 
obvious to one of ordinary skill in the art at the time of the invention to have used USB 
super frames to send large bursts of video data between remote unit 108 A (terminal) and 
user terminal 1 18A (host) because there would be no other device to contend with for the 
USB bus's cycle or bandwidth. 

Bradshaw et al in view of Cheng et al and Dillon et al, 
further in view of Birdwell et al 

19. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et 
al., Cheng et al., and Dillon et al. as applied to claim 25 above, and further in view of 
Birdwell et al. 

20. With regard to claim 30, Bradshaw et al. does not specifically disclose little and big 
endian data formats. However, Birdwell et al. discloses endian formats for IP packets 
transmitted over a satellite link [paragraph 0058]. Bradshaw et al. requires the 
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determination of the beginning, the end, the LSB, and/or the MSB of the transmitted data 
frames in order to process the data frames. Endian formats aid in determining whether 
the first bytes in the transmitted frames are the LSB or MSB. Thus, it would have been 
obvious to one of ordinary skill in the art at the time of the invention to have used the 
teachings of Bradshaw et al. in processing of transmitted data frames to have used the 
endian formats to aid in determining the LSB and MSB so that data alignment can be 
achieved at the receiver for either synchronization or CRC calculations. 



Bradshaw et al. in view of Cheng et al. and Dillon et al., 
further in view of Jorgenson et al. 

21. Claim 31 is rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et 
al. in view of Cheng et al. and Dillon et al. as applied to claim 25 above, and further in 
view of Jorgenson et al. (USP 6,680,922). 

22. With regard to claim 31, Bradshaw et al. does not specifically disclose IGD packets. 
However, Jorgenson discloses UDP for transmission of packets over a wireless link [col. 
12, lines 46-48]. IGD packets are formed from UDP packets. Therefore, it is obvious to 
those of ordinary skill in the art that UDP datagrams convey useful information 
parameters about the wireless link including the return channel ID and loading 
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information. Moreover, UDP/IP packets encapsulate multiple data types, including IGD 
packets. 

Response to Arguments 

23. Applicant's representative and examiner conducted a telephonic interview. No 
agreement was reached. 

24. Applicant's representative argues that the receiver unit is configured to translate data 
received from a host to a data format that conforms to a predetermined protocol 
supported by the hub and, thus, provides data to the transmitter already in a format 
suitable for transmission to the hub [Applicant's Response dated June 2, 2006, page 9, 
lines 23-28]. However, in addition to what is written in the rejections above, examiner 
interprets that the recitation of "configured to translate data" [in independent claims 1, 9, 
17, and 25] does not affirmatively recite the conversion/translation of the data form one 
protocol to another. Thus, the claim can be further interpreted as not performing the 
conversation/translation at all, rendering applicant's representative's arguments 
inapplicable. Assuming, arguendo, that the claim affirmatively recited the translation of 
host data from one protocol to another, the rejection above specifically encompasses data 
that is translated into a format suitable for transmission to the hub because any data 
transmission between the receiver and transmitter, or from satellite to hub, is in a format 
suitable for transmission to the hub [it is inherently the nature of packet transmissions]. 
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25. Applicant's representative argues that Bradshaw et al. fails to disclose, apparently, a 
physical interface that permits data exchange between a receiving unit and a transmitting 
unit in a single terminal [Applicant's Response dated June 2, 2006, page 10, lines 15- 
17]. First, In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., a physical interface between a receiving unit and a transmitting unit within a single 
terminal) are not recited in the rejected claims. Although the claims are interpreted in 
light of the specification, limitations from the specification are not read into the claims. 
See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Second, as 
explained in the rejections above, Bradshaw et al. discloses, teaches, and/or suggests 
several interfaces. Specifically, Bradshaw et al. is interpreted as encompassing the 
interface that permits translation of data from one protocol to another [i.e., terminal 
interface]. 



26. Applicant's representative further argues that Bradshaw et al. fails to disclose a 
receiving unit that translates data received from a host to a data frame that is supported by 
the hub [Applicant's Response dated June 2, 2006, page 10, lines 17-18]. However, in 
addition to what is written in the rejections above, examiner interprets that the recitation 
of the receiving unit that is "configured to translate data" [in independent claims 1, 9, 17, 
and 25] does not affirmatively recite the conversion/translation of the data form one 
protocol to another. Thus, the claim can be further interpreted as not performing the 
conversation/translation at all, rendering applicant's representative's arguments 
inapplicable. Assuming, arguendo, that the claim affirmatively recited the translation of 
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host data from one protocol to another, the rejection above specifically encompasses data 
that is translated into a format suitable for transmission to the hub because any data 
transmission between the receiver and transmitter, or from satellite to hub, is in a format 
suitable for transmission to the hub [it is inherently the nature of packet transmissions]. 

Conclusion 

27. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the 
extension of time policy as set forth in 37 CFR 1.136(a). 

28. A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the 
advisory action. In no event, however, will the statutory period for reply expire later than 
SIX MONTHS from the mailing date of this final action. 

29. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Mark A. Mais whose telephone number is 572-272-3138. 
The examiner can normally be reached on M-Th 5am-4pm. 
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30. If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Seema Rao can be reached on 571-272-3174. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

3 1 . Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO 
Customer Service Representative or access to the automated information system, call 
800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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